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Description 

A SYSTEM AND METHOD FOR 
COORDINATED REMOTE ACTIVATION 
OF MULTIPLE SOFTWARE-BASED 

OPTIONS 

Background of Invention 

[0001] The present invention relates generally to a system to en- 
able software- based options, and more particularly, to a 
system and method to automatically respond to a request 
for activation of software options resident on remote de- 
vices within a particular site. The invention includes auto- 
matically identifying the devices, verifying the status of 
each remote device and, if a remote device is in condition 
for activation, automatically activating the desired option. 

[0002] Medical diagnostic devices and supporting systems, such 
as medical imaging systems, have become increasingly 
complex in recent years. Examples of such systems in- 
clude magnetic resonance imaging (MR!) systems, com- 



puted tomography (CT) systems, ultrasound and x-ray 
systems, and positron emission tomograpliy (PET) sys- 
tems. These systems include many different software- 
based options, some of which are not used depending on 
customer needs and costs. To add to the complexity of 
each particular imaging system, many facilities today in- 
corporate a variety of such devices all of which may not be 
configured identically. In larger facilities, the systems may 
be networked to permit common management and con- 
trol. Further, such systems may be networked with a pic- 
ture archiving and communication system (PACS) for stor- 
ing digitized image data for subsequent retrieval and re- 
construction. Additionally, teleradiology systems that in- 
volve transmitting digitized image data to remote loca- 
tions for review and diagnosis by specialized physicians 
and/or radiologists may be used as well. 
[0003] Because these medical diagnostic systems are used by 
different facilities with differing needs, not all of these 
systems operate identically. That is, although identical 
software may be installed at the factory, certain options 
are not desired or licensed by a customer or user, and 
therefore are not enabled when delivered. If a customer 
later wants to add these options to their devices, a license 



would need to be executed and service personnel with ap- 
propriate training would have to physically travel to the 
location where the devices are present to enable the soft- 
ware in order for the customer to gain access to a particu- 
lar option. 

[0004] Improvements in computer networks have greatly facili- 
tated the task of offering assistance to remote facilities 
with medical imaging devices. In particular, rather than 
having to call a service center and speak with a technician 
or engineer, or await the arrival of a field engineer, net- 
work technologies have facilitated proactive techniques 
wherein the service center may contact the medical diag- 
nostic devices directly to check the status of the remote 
devices. 

[0005] While such advancements in the provision of remote ser- 
vices to medical diagnostic devices have greatly enhanced 
the level of service and information exchange, they have 
not been used to remotely identify and verify a site con- 
sisting of a plurality of networked in-field devices to 
thereby grant access to and permit use of software op- 
tions resident on the in-field devices incorporated within 
a particular site. 

[0006] There is a need for a system where a qualified customer 



can activate particular options already resident in memory 
of devices within the customer's system without requiring 
multiple levels of human interaction to ensure that en- 
abling the particular options is possible and can be imple- 
mented on each of the desired devices. That is, a system 
is needed to allow the customer to activate options of 
multiple devices within a site without an arduous process 
of manually evaluating each device in the site. 
[0007] It would therefore be desirable to have a system to auto- 
matically identify each device within a remote site, verify 
the current status of the devices and, if the current status 
of the device is such that activation of the particular op- 
tion is appropriate, automatically activate desired options 

on each of the devices within the site. 
Brief Description of Invention 

[0008] The present invention is directed to a system and method 
to automatically respond to a request for activation of 
software options resident on remote devices within a par- 
ticular site that overcomes the aforementioned drawbacks. 
The invention includes automatically identifying the de- 
vices, verifying the status of each remote device and, if a 
remote device is in condition for activation, automatically 
activating the desired option. 



[0009] In accordance with one aspect of the invention, an auto- 
mated method of remotely activating options resident on 
a plurality of devices is disclosed. The method includes 
generating a number of activation keys, each of which is 
specific to one of a plurality of in-field devices having in- 
active options resident in a memory of each of the plural- 
ity of in-field devices, and sending each representative 
activation key and a verification script to each of the in- 
field devices. The method then includes receiving a report 
from each of the verification scripts and evaluating each 
report independently, whereby if the report is satisfactory 
for a corresponding in-field device, the respective activa- 
tion key is installed in the corresponding in-field device to 
activate an option and, if the report is not satisfactory, for 
a corresponding in-field device, aborting activation of the 
option for the corresponding in-field device. 

[0010] In accordance with another aspect of the invention, a sys- 
tem to respond to a request to remotely enable options 
resident in the memory of a plurality of in-field devices is 
disclosed. The system includes a centralized facility lo- 
cated remotely from a plurality of in-field devices having 
inactive options. The centralized facility has at least one 
computer programmed to select verification scripts to 



check that each of the plurality of in-fleld devices is in 
condition to activate an inactive option and select activa- 
tion keys unique to each of the plurality of in-field de- 
vices. The at least one computer is also programmed to 
send at least one verification script and at least one acti- 
vation key to each of the plurality of in-field devices 
wherein each of the in-field devices is capable of execut- 
ing the verification script and independently aborting acti- 
vation of inactive option if a report indicates that one of 
the plurality of in-field devices is not in a condition to ac- 
tivate the inactive option. 
1] In accordance with yet another aspect of the invention, a 
system to remotely enable options through a network of 
in-field devices is disclosed that includes a network of in- 
field devices located remotely from a centralized facility. 
The network of in-field devices is programmed to send a 
single access request to the centralized facility to request 
activation of options of the in-field devices, receive acti- 
vation keys uniquely configured to activate the options of 
the in-field devices and verification scripts to authenticate 
a current status each of the in-field devices, and send a 
report generated by the verification scripts to the central- 
ized facility indicating the current status of the in-field 



devices. The network of in-field devices is further pro- 
grammed to install one activation key in one of the in- 
field devices to activate the options in the one in-field de- 
vice if the current status of the one in-field device is de- 
termined to be satisfactory by the centralized facility, and 
continue to send a report generated by the verification 
scripts and install one activation key for each of the in- 
field devices of the network. 
[0012] Various other features, objects and advantages of the 

present invention will be made apparent from the follow- 
ing detailed description and the drawings. 
Brief Description of Drawings 

[0013] The drawings illustrate a preferred embodiment as 

presently contemplated for carrying out the invention. 
[0014] In the drawings: 

[0015] Fig. 1 is a block diagram of a system for which the present 

invention is implemented therein. 
[0016] Fig. 2 is a flow chart showing a process of the present in- 
vention and implemented in the system of Fig. 1. 
Detailed Description 

[0017] The present invention is directed to a technique to auto- 
matically identify multiple devices within a site, verify the 



settings of each device, and, if in proper condition, enable 
an inactive software option resident in eacli device. 

[0018] Referring to Fig. 1, an overview blocl< diagram of a medi- 
cal diagnostic and service networked system 10 is shown 
which includes a plurality of remote customer stations, 
such as Customer A in a customer station 12 and Cus- 
tomer B in another customer station 14. It is understood 
that the number of customer stations can be limitless, but 
two specific embodiments are shown with Customer A and 
Customer B, which will be further explained hereinafter. 
The customer stations 12, 14 are connected to a central- 
ized facility 16 through a communications link, such as a 
network of interconnected server nodes/Internet 18 or a 
remote link 20. Although a single centralized facility 16 is 
shown and described, it is understood that the present in- 
vention contemplates the use of multiple centralized facil- 
ities, each capable of communication with each customer 
station. Each customer station has operational software 
associated therewith which can be configured, serviced, 
maintained, upgraded, monitored, enabled or disabled by 
the centralized facility 16. 

[0019] The various systems disclosed are configured to be selec- 
tively linked to the centralized facility 16 by either the re- 



mote link 20, or in tlie example of customer station 12, a 
laptop computer 22 connected to an internal network 24 
of Customer A. Such selective linking is desirable to pro- 
vide upgrades, maintenance, service, and general moni- 
toring of the various systems and equipment at a cus- 
tomer site, which includes accessing data from the sys- 
tems and transmitting data to the systems, for example. 
[0020] In general, a customer site may have a number of devices 
such as a variety of medical diagnostic systems of various 
modalities. As another example, in the present embodi- 
ment, the devices may include a number of networked 
medical image scanners 26 connected to an internal net- 
work 24 served by a single scanner 28 having a worksta- 
tion configured to also act as a server, or configured as a 
stand-alone server without a medical image scanner as- 
sociated therewith. Alternately, a customer station, or 
customer site 14 can include a number of non-networked 
medical image scanners 30, 32, and 34 each having a 
computer or work station associated therewith and having 
an internal modem 36, 38, and 40 to connect the remote 
customer station to a communications link, such as the 
Internet 18 through links 37, 39, and 41, respectively, to 
communicate with the centralized facility 16. Internet 18 



is shown in pliantom to indicate that an external commu- 
nications networl< can include Internet 18, together with 
communication links 29, 37, 39, and 41, or alternatively, 
can include direct dial-up links through dedicated lines, 
an intranet, or public communications systems. 

[0021] It is understood that each of the network scanners 26 has 
its own workstation for individual operation and are linked 
together by the internal network 24 so that the customer 
can have a centralized management system for each of 
the scanners. Further, such a system is provided with 
communications components allowing it to send and re- 
ceive data over a communications link 29. Similarly, for 
the non-networked medical image scanners at remote 
customer station 14, each of the scanners 30, 32, and 34 
have individual communications links 37, 39, and 41. Al- 
though Fig. 1 shows each of these links connected 
through an open network 18, these links can permit data 
to be transferred to and from the systems over a dedi- 
cated network as well. 

[0022] The embodiment shown in Fig. 1 contemplates a medical 
facility having such systems as magnetic resonance imag- 
ing (MR!) systems, ultrasound systems, x-ray systems, 
computed tomography (CT) systems, as well as positron 



emission tomograpliy (PET) systems, or any other type of 
medical imaging system, liowever, tlie present invention is 
not so limited. Such facilities may also provide services to 
centralized medical diagnostic management systems, pic- 
ture archiving and communications systems (PACS), tel- 
eradiology systems, etc. Such systems can be either sta- 
tionary and located in a fixed place and available by a 
known network address, or be mobile, having various net- 
work addresses. In the embodiment shown in Fig. 1, each 
customer station 12, 14 can include any combination of 
the aforementioned systems, or a customer station may 
have all of a single type of system. A customer station can 
also include a single medical image scanner. Mobile diag- 
nostic systems can be configured similarly to that of cus- 
tomer station 12 or customer station 14. Such mobile di- 
agnostic systems can include equipment of various 
modalities, such as MRI, CT, ultrasound, or x-ray systems 
and are mobilized in order to service patients at various 
medical facilities. 
[0023] A request for access and enablement of software-based 
options of the present invention can be initiated by au- 
thorized personnel, such as an on-line engineer or tech- 
nician, or customer administrative personnel from a com- 



puter or workstation 42 in tlie remote linl< 20, whicli can 
be a part of the centralized facility 16, or be separately 
connected to the centralized facility 16 by a dialup link 44 
to a web server 46 in the centralized facility 16. Alterna- 
tively, it is contemplated that the system could be initial- 
ized by a laptop computer 22 connected to a customer in- 
ternal network 24, or individually connected to each of the 
scanners 30, 32, or 34. The remote link 20 can also serve 
to connect the centralized facility 16 to a customer station 
by a telephone and telephone connection 48 through a 
conventional telephone network 50 and to an interactive 
voice recognition system (IVR) 52 in the centralized facility 
16. The centralized facility 16 includes a number of pro- 
cessing systems including computers for the IVR system 
52, an automated support center 54, the web server 46, 
and an auto checkout server 56, for processing customer 
and product data and creating an appropriate configura- 
tion file. Other processor systems include computers to 
maintain a voicemail system 58, a pager system 60, an 
email system 62, and a main frame 64, and more gener- 
ally, an output report generator and notifier. Each is con- 
nectable and can transmit data through a network, such 
as an Ethernet 66, with one another and/or with at least 



one database 68. However, it is understood that the single 
representation of a database in Fig. 1 is for demonstrative 
purposes only, and it is assumed that there is a need for 
multiple databases in such a system. It is also understood 
that the IVR system is not only a voice recognition system, 
but can also process interactive keypad entry from a 
touchtone telephone 48. A bank of modems 70 is con- 
nected to the Ethernet 66 to relay data from the central- 
ized facility 16 to the remote customer stations 12, 14 
through a plurality of modem links 72. Hence, a system to 
allow automatic remote transfer of data and communica- 
tions between the centralized facility 16 and a customer 
site 12, 14 is achieved. 
[0024] As previously discussed, each of the systems and substa- 
tions described herein and referenced in Fig. 1 may be 
linked selectively to the centralized facility 16 via a net- 
work 18. According to the present invention, any accept- 
able network may be employed whether public, open, 
dedicated, private, or so forth. The communications links 
to the network may be of any acceptable type, including 
conventional telephone lines, fiber optics, cable modem 
links, digital subscriber lines, wireless data transfer sys- 
tems, or the like. Each of the systems is provided with 



communications interface hardware and software of gen- 
erally known design, permitting them to establish network 
links and exchange data with the centralized facility 16. 
The systems are provided with interactive software so as 
to configure the systems and exchange data between the 
customer stations and the centralized facility 16. In some 
cases, during periods when no data is exchanged between 
the customer stations and the centralized facility, the net- 
work connection can be terminated. In other cases, the 
network connection is maintained continuously. 

[0025] The present invention includes a technique for reviewing a 
remote device for a current status, and if approved for ac- 
tivation, granting access to and remotely permitting use 
of resident software options in the remote device. As pre- 
viously indicated, the device, including medical imaging 
equipment, includes installed software that controls op- 
tions that are can be enabled or disabled automatically. 
The present invention is directed toward an expeditious 
method and system to automatically and remotely access 
in-field devices within a common site, verify the current 
status of each in-field device, and enable options resident 
on each in-field device. 

[0026] From a centralized facility, and after appropriate authenti- 



cation of the user and validation of tlie system identifica- 
tion and customer's status, an electronic enabler is gener- 
ated in the centralized facility 16 and electronically trans- 
mitted to a device via the communication links 29, 37, 39, 
41, and/or 72, preferably over a private communication 
link, but other public communications systems can work 
equally well, such as direct dial-up internet or wireless 
communications. As previously set forth, it is understood 
that the external communications links include a closed 
intranet system, an open public communications system, 
or a combination thereof. 
[0027] Referring to Fig. 2, the technique is initiated 100 when a 
system identification including a customer identification is 
sent from a remote customer station or a remote link and 
received at the centralized facility 102. It is contemplated 
that the system identification may include or reference 
billing account information and a unique site identifica- 
tion. As such, it is possible to identify both the customer 
and the customer's site from the system identification. It 
is contemplated that the system identification constitutes 
the initiation of an enablement request. That is, the re- 
questing device may have been originally purchased hav- 
ing a plurality of options and, due to pricing considera- 



tions, the device was purchased with some of the options 
initially disabled. Therefore, the initial purchase of the 
hardware of the device included a wide variety of options 
and the customer may have chosen that specific options 
be disabled to reduce the overall purchase price of the 
device. Accordingly, after purchase, the customer may 
make an enablement or activation request to enable any 
of the options resident on the device at the time of pur- 
chase but disabled due to pricing choices. It is further 
contemplated that the activation request may be to enable 
options added after the initial purchase as part of an up- 
date or upgrade but disabled to reduce the price of the 
upgrade or update. 

[0028] After receiving the system identification, the centralized 
facility then validates the system identification at 104. 
Validation is determined according to the customer iden- 
tification and/or a passphrase from the system identifica- 
tion. The centralized facility identifies the customer mak- 
ing the request and the customer's in-field devices. If the 
customer identification is not valid 106, a prompt for en- 
try of a valid customer identification is made 108. 

[0029] After the system identification is validated 104, 110, a site 
activation request is sent from the remote customer site 



and received by the centralized facility 112. The central- 
ized facility then validates the activation request at 114. 
Specifically, the centralized facility makes an initial review 
of the activation request by comparing the system identi- 
fication to the activation request. The centralized facility 
determines whether the in-field devices within the site are 
capable of the activation requested. For example, the cen- 
tralized facility determines whether the in-field devices 
are of a modality that are operable with the requested op- 
tion or whether the requested activation has previously 
been made and fulfilled, and therefore, the options are al- 
ready enabled in the in-field devices of the customer's 
site. 

[0030] If the activation request 112 is determined to be invalid 
116, e.g., does not register the requesting site to include 
in-field devices supporting the software- based options 
requested or the requested options are already active 
within the particular in-field devices, a message is re- 
turned to the in-field device to prompt manual contact 
with the centralized facility 118 and the activation is 
aborted 120. 

[0031] However, if the activation request is determined to be 

valid 122, the centralized facility requests a host identifi- 



cation from each of the in-field devices within the site 
124. These unique host identifications indicate the 
specifics of the particular in-field device to the centralized 
facility. Based on the each host identification, the central- 
ized facility generates an activation key specifically con- 
figured for a particular in-field device to activate the de- 
sired options upon installation in the particular in-field 
device 126. Furthermore, the centralized facility selects a 
verification script appropriate to determine a current sta- 
tus of the particular in-field device 128. Once the activa- 
tion key has been generated 126 and the verification 
script selected 128, the centralized facility sends the key 
and script to the in-field device 130. It is contemplated 
that script and key may be sent to each in-field device in a 
single transmission or through multiple transmissions. 
Furthermore, it is contemplated that each key and script 
may be bundled together to create a single package that 
is sent to each in-field device. It is further considered that 
the single package may be compressed and/or encrypted 
to expedite and secure transmission. 
[0032] When a particular in-field device receives the key and 
script, the device unbundles the package, if necessary, 
and executes the verification script 132. The verification 



script is configured to automatically determine a current 
status of the particular in-field device for which it was 
generated in order to compile information about the cur- 
rent status of the particular in-field device that is relevant 
to activation of the requested option. Specifically, the ver- 
ification script gathers a plurality of current settings of the 
in-field device and generates a report. For example, the 
verification script may determine any options currently 
active on the particular in-field device, options supported 
by the particular in-field device, any dependencies of op- 
tions supported by the particular in-field device, as well 
as other similar settings. As such, the report contains in- 
formation regarding the enableability of the in-field de- 
vice with respect to the requested option. That is, the in- 
formation included in the report pertains to the current 
setting of the in-field device and whether under those 
settings the in-field device is able to have the requested 
option enabled, i.e. the enableability of the in-field device. 
The information is then used by the verification script to 
generate a report that is sent by the in-field device and 
received by the centralized facility 134. 
[0033] It is contemplated that the reports from each particular 
in-field device of the site may be sent individually to the 



centralized facility. As such, the centralized facility re- 
ceives each report individually and evaluates each report 
as received individually 136. Therefore, if a particular re- 
port from an individual in-field device is deemed unap- 
proved, a message to prompt contact of the centralized 
facility is sent pertaining to the individual in-field device. 
Accordingly, the reports pertaining to the in-field devices 
are received and evaluated independently. 

[0034] Alternatively, it is contemplated that the reports from the 
in-field devices may be bundled and sent in a single 
transmission to the centralized facility once all the reports 
are generated. The transmission is sent as a compact file 
that is received at the centralized facility. As such, the 
centralized facility waits for the single transmission rather 
than each individual report and then unbundles the re- 
ports. However, while the receipt of the bundle includes 
the reports from each in-field device, the reports are in- 
dependently evaluated 136. As such, if a report pertaining 
to an individual in-field device is deemed approved 138 or 
unapproved 140, the approval 138 or disapproval 140 of 
the remaining in-field devices is uninfluenced. 

[0035] Furthermore, it is contemplated that a single report incor- 
porating all of the reports from each of the particular in- 



field devices may be compiled and sent to the centralized 
facility. Specifically, should the site include a server con- 
figured to coordinate communication between the site and 
the centralized facility, the reports from the in-field de- 
vices are received by the server and then used to generate 
a single, master report that includes the information from 
the reports from each particular in-field device. The 
server then sends the single report to the centralized fa- 
cility. Again, however, when evaluating the single report 
136, the centralized facility reviews each portion of the 
single report that pertains to a particular in-field device 
independently. Therefore, whether a particular in-field 
device is approved 138 or disapproved 140 does not In- 
fluence the approval or disapproval of the other in-field 
devices. 

[0036] However, it is also contemplated that the report may be 
evaluated as a whole. Accordingly, when the single, mas- 
ter report is received, the report is evaluated and all de- 
vices within the site are either approved 138 or disap- 
proved 140 together. As such, whether a particular in- 
field device is approved 138 or disapproved 140 does in- 
fluence the approval or disapproval of the other in-field 
devices. Accordingly, the entire site is effectively approved 



or disapproved. 

[0037] To determine wlietlier to approve 138 or disapprove 140 
activation of an option resident on a particular in-field 
device, the centralized facility evaluates the report 136 to 
determine the enableability of the particular in-field de- 
vice with respect to the requested option. If the report in- 
dicates the device is enableable, the report is approved 
138 and the centralized facility permits installation of the 
activation key in the in-field device 138. Specifically, the 
centralized facility sends an approval to the particular in- 
field device whereby the particular in-field device installs 
the activation key enabling the option 142. Following in- 
stallation, the centralized facility may monitor the use of 
the option. As such, the activation key may contain a 
present expiration time, whereby the centralized facility 
may warn the customer of an impending expiration. 
Should the customer elect to reactivate the option, the 
steps described above are repeated and the option is re- 
activated. 

[0038] Following approval of a particular in-field device, the cen- 
tralized facility checks to determine whether all in-field 
devices of the site have been evaluated 144. It is contem- 
plated that this review of the site may be accomplished 



through a number of procedures. For example, should the 
centralized facility serially evaluate each in-field device of 
the site, the centralized facility reviews the host identifi- 
cations received from each device 124, and if a key has 
not been generated for a particular host identification 
146, then the centralized facility repeats the above de- 
scribed process beginning with the generation of a activa- 
tion key that is specific to the particular host identification 
126. 

[0039] It is also contemplated that the centralized facility may 

service each in-field device in parallel. In this case, to de- 
termine whether all in-field devices have been evaluated 
146, the centralized facility checks that a report has been 
received from each of the in-field devices. If a report cor- 
responding to each of the scripts that were sent 130 has 
not been received, the centralized facility waits until such 
report is received 134 and continues by evaluating the re- 
port. In any case, once the centralized facility determines 
that all in-field devices have been evaluated 148, the site 
activation is complete and the process ends. 

[0040] However, if a report indicates that the desired option can- 
not readily be activated, the centralized facility does not 
approve the report 140. Accordingly, a message is re- 



turned to the in-field device to prompt manual contact 
with the centralized facility 118 and the activation is 
aborted 120. Specifically, the particular in-field device 
from which the report was generated is identified in the 
message and the activation process for the particular in- 
field devices is complete 120. However, it is contemplated 
that disapproval of the report pertaining to a particular 
in-field device 140 does not affect the enableability of 
other in-field devices within the site. Therefore, while the 
activation process pertaining to a particular in-field device 
may be completed without effectuating activation of the 
desired option, the desired option may be enabled in 
other in-field devices of the site and the activation for the 
remaining in-field devices is continued. 

[0041] Accordingly, the present invention includes a method to 
simultaneously and remotely activate options resident in 
the memory of a plurality of in-field devices within a site 
without compromising the functionality of the in-field de- 
vices within the site. 

[0042] It is contemplated that the above-described technique 
may be embodied as an automated method of remotely 
activating options resident on a plurality of devices. The 
method includes generating a number of activation keys. 



each of which is specific to one of a plurality of in-field 
devices having inactive options resident in a memory of 
each of the plurality of in-field devices, and sending each 
representative activation key and a verification script to 
each of the in-field devices. The method then includes re- 
ceiving a report from each of the verification scripts and 
evaluating each report independently, whereby if the re- 
port is satisfactory for a corresponding in-field device, the 
respective activation key is installed in the corresponding 
in-field device to activate an option and if the report is 
not satisfactory for a corresponding in-field device, 
aborting activation of the option for the corresponding in- 
field device. 

[0043] It is further contemplated that the above-described tech- 
nique may be embodied as a system to respond to a re- 
quest to remotely enable options resident in the memory 
of a plurality of in-field devices. The system includes a 
centralized facility located remotely from a plurality of in- 
field devices having inactive options. The centralized fa- 
cility has at least one computer programmed to select 
verification scripts to check that each of the plurality of 
in-field devices is in condition to activate an inactive op- 
tion and select activation keys unique to each of the plu- 



rality of in-field devices. Tlie at least one computer is also 
programmed to send at least one verification script and at 
least one activation key to each of the plurality of in-field 
devices wherein each of the in-field devices is capable of 
executing the verification script and independently abort- 
ing activation of inactive option if a report indicates that 
one of the plurality of in-field devices is not in a condition 
to activate the inactive option. 
[0044] It is also contemplated that the above-described tech- 
nique may be embodied as a system to remotely enable 
options through a network of in-field devices that in- 
cludes a network of in-field devices located remotely from 
a centralized facility. The network of in-field devices is 
programmed to send a single access request to the cen- 
tralized facility to request activation of options of the in- 
field devices, receive activation keys uniquely configured 
to activate the options of the in-field devices and verifica- 
tion scripts to authenticate a current status each of the 
in-field devices, and send a report generated by the veri- 
fication scripts to the centralized facility indicating the 
current status of the in-field devices. The network of in- 
field devices is further programmed to install one activa- 
tion key in one of the in-field devices to activate the op- 



tions in the one in-field device if tlie current status of tlie 
one in-field device is determined to be satisfactory by the 
centralized facility, and continue to send a report gener- 
ated by the verification scripts and install one activation 
key for each of the in-field devices of the network. 
[0045] The present invention has been described in terms of the 
preferred embodiment, and it is recognized that equiva- 
lents, alternatives, and modifications, aside from those 
expressly stated, are possible and within the scope of the 
appending claims. 



